Skip to content

fix: Default to day-first format for invalid/unknown locales#1168

Merged
nathan-stender merged 1 commit into
mainfrom
fix/timestamp-invalid-locale-default
Apr 8, 2026
Merged

fix: Default to day-first format for invalid/unknown locales#1168
nathan-stender merged 1 commit into
mainfrom
fix/timestamp-invalid-locale-default

Conversation

@nathan-stender

Copy link
Copy Markdown
Collaborator

Summary

Fixes a bug where invalid/unknown locales would default to month-first (American) format instead of day-first format. Since most of the world uses day-first, this is the better default.

Problem

When an invalid or unknown locale was provided (e.g., typo, unsupported locale), the exception handler would return False (month-first):

except Exception:
    return False  # ❌ Defaults to month-first (MM/DD/YYYY)

This caused incorrect parsing:

  • User provides locale="xyz_ABC" (typo)
  • Date "01/02/2023" gets parsed as January 2nd (month-first)
  • Should be parsed as February 1st (day-first, more common globally)

Why this is wrong

Only a handful of locales use month-first format:

  • en_US - American English
  • A few Pacific island locales

Most of the world uses day-first:

  • All of Europe
  • Most of Asia
  • Middle East
  • Africa
  • South America
  • Australia

Solution

Changed exception handler to return True (day-first) for invalid locales:

except Exception:
    # Invalid/unknown locale: default to day-first since most of the world uses it
    # Only en_US and a few other locales use month-first (MM/DD/YYYY)
    return True  # ✅ Defaults to day-first (DD/MM/YYYY)

The logic now:

  1. ISO 8601 (YYYY-MM-DD) → False (month before day)
  2. No locale (None) → False (backward compat, American default)
  3. Valid locale → Check Babel CLDR data
  4. Invalid localeTrue (day-first is global default)

Code Changes

Before:

except Exception:
    return False  # Defaulted to month-first

After:

except Exception:
    # Invalid/unknown locale: default to day-first since most of the world uses it
    # Only en_US and a few other locales use month-first (MM/DD/YYYY)
    return True  # Default to day-first (DD/MM/YYYY)

Testing

Updated test:

def test_invalid_locale_returns_true(self) -> None:
    # Invalid/unknown locales default to day-first since most of world uses it
    assert _should_use_day_first("01/15/2023", "invalid_LOCALE") is True
    assert _should_use_day_first("15/01/2023", "xyz_ABC") is True

New integration test:

def test_invalid_locale_defaults_to_day_first(self) -> None:
    parser = TimestampParser()
    
    # With an invalid locale, ambiguous dates should parse as day-first
    with set_locale_context("invalid_LOCALE"):
        result = parser.parse("01/02/2023")
    assert "2023-02-01" in result  # February 1st (day-first)
  • ✅ All 19 timestamp parser tests pass
  • ✅ All 547 tests pass
  • ✅ Linting clean

Impact

  • Fixes bug - Invalid locales now use the globally more common format
  • Better user experience - Fewer parsing errors for international users
  • No breaking changes - Only affects invalid locale case (which was already broken)
  • Backward compatible - None locale still defaults to American format

🤖 Generated with Claude Code

## Problem
Previously, when an invalid or unknown locale was provided, the code would
catch the exception and default to month-first (American) format by returning
False. This is incorrect because:

1. Most of the world uses day-first format (DD/MM/YYYY)
2. Only en_US and a few other locales use month-first (MM/DD/YYYY)
3. Defaulting to the less common format causes more parsing errors

Example bug:
- User provides locale "xyz_ABC" (typo or unknown locale)
- Date "01/02/2023" gets parsed as January 2nd (month-first)
- Should be parsed as February 1st (day-first, more common globally)

## Solution
Changed the exception handler in `_should_use_day_first()` to return True
(day-first) instead of False (month-first) for invalid locales.

The logic now:
- locale_str is None → False (backward compat, American default)
- Valid locale → check Babel CLDR data
- Invalid locale → True (day-first is global default)

## Testing
- Updated test: `test_invalid_locale_returns_true()`
- Added test: `test_invalid_locale_defaults_to_day_first()`
- Confirms "01/02/2023" with invalid locale → February 1st (day-first)
- All 19 timestamp parser tests pass

Co-Authored-By: Claude Opus 4.1 <noreply@anthropic.com>
@nathan-stender
nathan-stender requested review from a team and slopez-b as code owners April 8, 2026 02:43
@nathan-stender
nathan-stender merged commit 881c264 into main Apr 8, 2026
9 checks passed
@nathan-stender
nathan-stender deleted the fix/timestamp-invalid-locale-default branch April 8, 2026 13:35
nathan-stender added a commit that referenced this pull request Apr 8, 2026
### Added

- Add locale-aware timestamp parsing using Babel CLDR data (#1167)
- Add global locale support for number parsing (#1165)
- Reduce Cytiva Biacore T200 Control memory usage with cycle streaming
(#1164)
- Cytiva T200 - Implement streaming decoder to reduce memory usage by
55% (#1163)

### Fixed

- Default to day-first format for invalid/unknown locales (#1168)
- Use immutable copy pattern for WellItem result attachment (#1166)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants